/**
 * Copyright (c) 2010 deniskir@gmail.com. All rights reserved.
 *
 * @author Denis Kiriusin
 */

package com.dksoftware.combo;

enum HttpHeaders {

    /**
     * An ETag, or entity tag, is part of HTTP, the protocol for the World Wide Web. It is one of
     * several mechanisms that HTTP provides for cache validation, and which allows a client to make
     * conditional requests. This allows caches to be more efficient, and saves bandwidth, as a web
     * server does not need to send a full response if the content has not changed. ETags can also
     * be used for optimistic concurrency control[1], as a way to help prevent simultaneous updates
     * of a resource from overwriting each other.
     * <p>
     * An ETag is an opaque identifier assigned by a web server to a specific version of a resource
     * found at a URL. If the resource content at that URL ever changes, a new and different ETag is
     * assigned. Used in this manner ETags are similar to fingerprints, and they can be quickly
     * compared to determine if two versions of a resource are the same or are different. Comparing
     * ETags only makes sense with respect to one URL ETags for resources obtained from different
     * URLs may or may not be equal and no meaning can be inferred from their comparison.
     * <p>
     * The use of ETags is optional, and the method by which they are generated is unspecified.
     * Common methods include utilizing a collision-resistant hash function of the resource's
     * content, a hash of the last modification timestamp, or even just a revision number. Care must
     * be taken to avoid simple methods, such as with many checksums, that are not
     * collision-resistant, as it can lead to inadvertent use of stale cached data.
     */
    Etag("Etag"),

    /**
     * The If-None-Match request-header field is used with a method to make it conditional. A client
     * that has one or more entities previously obtained from the resource can verify that none of
     * those entities is current by including a list of their associated entity tags in the
     * If-None-Match header field. The purpose of this feature is to allow efficient updates of
     * cached information with a minimum amount of transaction overhead. It is also used to prevent
     * a method (e.g. PUT) from inadvertently modifying an existing resource when the client
     * believes that the resource does not exist.
     */
    IfNoneMatch("If-None-Match"),

    /**
     * The Content-Length entity-header field indicates the size of the entity-body, in decimal
     * number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the
     * entity-body that would have been sent had the request been a GET.
     * <p>
     * <code>Content-Length: 3495</code>
     */
    ContentLength("Content-Length"),

    /**
     * The purpose of the Content-Type field is to describe the data contained in the body fully
     * enough that the receiving user agent can pick an appropriate agent or mechanism to present
     * the data to the user, or otherwise deal with the data in an appropriate manner.
     */
    ContentType("Content-Type"),

    /**
     * The Last-Modified entity-header field indicates the date and time at which the origin server
     * believes the variant was last modified.
     * <p>
     * <code>Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT</code>
     */
    LastModified("Last-Modified"),

    /**
     * The If-Modified-Since request-header field is used with a method to make it conditional: if
     * the requested variant has not been modified since the time specified in this field, an entity
     * will not be returned from the server; instead, a 304 (not modified) response will be returned
     * without any message-body.
     * <p>
     * <code>If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT</code>
     */
    IfModifiedSince("If-Modified-Since"),

    /**
     * The Content-Encoding entity-header field is used as a modifier to the media-type. When
     * present, its value indicates what additional content codings have been applied to the
     * entity-body, and thus what decoding mechanisms must be applied in order to obtain the
     * media-type referenced by the Content-Type header field. Content-Encoding is primarily used to
     * allow a document to be compressed without losing the identity of its underlying media type.
     * <p>
     * <code>Content-Encoding: gzip</code>
     */
    ContentEncoding("Content-Encoding"),

    /**
     * The Accept-Encoding request-header field is similar to Accept, but restricts the
     * content-codings that are acceptable in the response.
     * <p>
     * <code>Accept-Encoding: compress;q=0.5, gzip;q=1.0</code>
     */
    AcceptEncoding("Accept-Encoding"),

    /**
     * The Vary field value indicates the set of request-header fields that fully determines, while
     * the response is fresh, whether a cache is permitted to use the response to reply to a
     * subsequent request without revalidation. For uncacheable or stale responses, the Vary field
     * value advises the user agent about the criteria that were used to select the representation.
     * A Vary field value of "*" implies that a cache cannot determine from the request headers of a
     * subsequent request whether this response is the appropriate representation.
     */
    Vary("Vary"),

    /**
     * The Cache-Control general-header field is used to specify directives that MUST be obeyed by
     * all caching mechanisms along the request/response chain. The directives specify behavior
     * intended to prevent caches from adversely interfering with the request or response. These
     * directives typically override the default caching algorithms. Cache directives are
     * unidirectional in that the presence of a directive in a request does not imply that the same
     * directive is to be given in the response.
     */
    CacheControl("Cache-Control"),

    /**
     * The Expires entity-header field gives the date/time after which the response is considered
     * stale. A stale cache entry may not normally be returned by a cache (either a proxy cache or a
     * user agent cache) unless it is first validated with the origin server (or with an
     * intermediate cache that has a fresh copy of the entity). See section 13.2 for further
     * discussion of the expiration model.
     * <p>
     * The presence of an Expires field does not imply that the original resource will change or
     * cease to exist at, before, or after that time.
     * <p>
     * The format is an absolute date and time as defined by HTTP-date in section 3.3.1; it MUST be
     * in RFC 1123 date format:
     * <p>
     * <code>Expires: Thu, 01 Dec 1994 16:00:00 GMT</code>
     */
    Expires("Expires");

    private final String name;

    HttpHeaders(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

}
